漫谈数仓建模之 范式模型

福利活动：送书啦！《实时流计算系统设计与实现》

如果你还记得的话，我们之前一起学习分享过 系列 | 漫谈数仓第二篇NO.2 数据模型 ，今天我们再一起深入理解一下范式建模。

范式建模是数据仓库建模的其中一种方法，范式建模不仅在线上业务数据库中展现了强劲的风采，也在数据仓库侧发挥着重要的作用。范式建模的难度在于如何抽象业务，来进行DW建设前夕的准备工作。建好了这一层的数据模型，对于DW层数据的建设，将是大大的提高了效率和大大的降低了复杂性。

W. H.Inmon企业信息化工厂架构图

图片来源网络

0x01 背景

范式模型即实体关系（ER）模型，是数据仓库之父W.H.Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构，从关系型数据库的角度出发，结合了业务系统的数据模型，站在企业级的高度设计一个3NF模型，实现数据仓库的建模。

0x02 范式模型之三大范式

1、第一范式（1NF）：原子性，列不可再分，每一列只包含一个属性，所有属性的类型都是一样的，而不能是集合，数组，记录等非原子数据项，即实体中的某个属性有多个值时，必须拆分为不同的属性。这是所有关系型数据库的最基本要求；

2、第二范式（2NF）：唯一性，一个表只说明一个事物，要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只描述一件事情；

（1）函数依赖

若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X--->Y。简单说就是，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系y= f(x)，在x的值确定的情况下，y的值一定是确定的。

举个例子，假设公民表中的字段（身份证号、姓名、联系方式、联系内容），找不到任何一条记录，它们的身份证号相同而对应的姓名不同。所以我们可以说姓名函数依赖于身份证号，写作“身份证号--->姓名”。但是反过来，因为可能出现同名的人，所以有可能不同的两条记录，它们在姓名上的值相同，但对应的身份证号不同，所以我们不能说身份证号函数依赖于姓名。

A、完全函数依赖

在一张表中，若 X--->Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ --->Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作 X F--->Y。

举个例子，因为同一个人的身份证号对应的联系内容不确定，同一个联系方式对应的联系内容也不确定。

B、部分函数依赖

Y函数依赖于X，但同时Y并不完全函数依赖于X，那么我们就称Y部分函数依赖于X，记作 X P--->Y。

举个例子，（身份证号，联系方式）--->姓名是“部分函数依赖”，姓名、只依赖于主键中的身份证号，与联系方式无关。

C、传递函数依赖

举个例子，工作领导依赖于公司，与身份证号无关，与联系方式也无关；又因公司依赖于身份证号，所以工作领导间接依赖于身份证号。

（2）码

设K为某表中的一个属性或属性组，若除K之外的所有属性都完全函数依赖于K（这个“完全”不要漏了），那么我们称K为候选码，简称为码。在实际中我们通常可以理解为：假如当K确定的情况下，该表除K之外的所有属性的值也就随之确定，那么K就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）

例如：假设公民表中的字段（身份证号、姓名、联系方式，联系内容），（身份证号、联系方式）这个属性组就是码。该表中有且仅有这一个码，相当于表的唯一约束。

（3）非主属性

包含在任何一个码中的属性成为主属性，举个例子，假设公民表中的字段（身份证号、姓名、联系方式，联系内容），主属性有两个身份证号、联系方式。

（4）判断符合第二范式要求的方法

终于可以回过来看2NF了。首先，我们需要判断，表是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：

第一步：找出数据表中所有的码

第二步：根据第一步所得到的码，找出所有的主属性

第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了

第四步：查看是否存在非主属性对码的部分函数依赖

3、第三范式（3NF）：每列都与主键有直接关系，属性不能传递依赖于主属性。

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。

符合第三范式的关系必须具有以下三个条件：

第一、每个属性的值唯一，不具有多义性

第二、每个非主属性必须完全依赖于整个主键，而非主键的一部分

第三、每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

0x03 范式模型的特点

• 同一份数据只存放在一个地方，因此只能从一个地方获取，没有数据冗余，保证了数据一致性。

• 解耦（系统级与业务级），方便维护

• 设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解耦，易维护，缺点是开发周期一般比较长，维护成本高。

0x04 范式模型的优缺点

1、优点

从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。

2、缺点

由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性、性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。

0x05 范式模型应用场景

通过范式模型构建一个符合三范式的集中式的数据中心DW层，此层次的表一般不对BI和应用开放，而是基于DW的数据构建数据集市DM层来对外服务，DM层的数据一般也采用范式建模。不过随着对分析决策的需求，融入了维度建模的思想，采用维度建模构建出来的数据模型更加符合普通人的认知、易于被普通人所理解，从而有利于数据的推广使用，但是并未提出使用一致性维度。

---

如果感觉文章有用，请分享给你的朋友哦！还有福利送书活动等你来，点击直达：送书啦！《实时流计算系统设计与实现》

欢迎加入 技术交流群。戳：快来加入数据交流群吧～

推荐阅读

1.   数据治理 | 美团配送数据治理实践
   

觉得内容不错的话 请分享到朋友圈哦~
▼ 福利时刻 ▼ 

01. 后台回复「经典」,即可领取大数据数仓经典书籍。

02. 后台回复「中台」,即可领取大厂中台架构高清ppt。

03. 后台回复「加群」,或添加小助微信ID：iom1128  拉您入群（备注方向：大数据|数仓|分析|Flink|资源|python|爬虫）或领取资料。

Q: 关于实时数仓，你还想了解什么？

欢迎留言区与大家分享

觉得不错，请把这篇文章分享给你的朋友哦

入群请联系小助手：iom1128『紫霞仙子』

更多精彩，请戳"阅读原文"到"数仓之路"查看

 

       ！关注不迷路~ 各种干货、资源定期分享！ 

要看更多，请点击左下角阅读原文即可阅读整理好的我的所有文章！